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METHOD AND SYSTEM FOR PROVIDING A LINKAGE BETWEEN 
SYSTEMS MANAGEMENT SYSTEMS AND APPLICATIONS 

BACKGROUND OF THE INVENTION 

Technical Field 

The present invention relates to a method and system for 
providing improving interaction between systems 
management systems and their respective distributed 
applications running in networked computer systems. In 
particular, the present invention relates to a method and 
system for providing an improved consistency between 
systems management systems and their respective 
distributed applications. 

Prior Art 

The subject matter of the present invention is applicable 
to a broad variety of applications, i.e. whenever the 
availability of an application is monitored by systems 
management systems, further referred to as SMSs. 

It is particularly applicable for applications having a 
distributed nature and running in a distributed 
environment on a plurality of workstations hosting some 
copy of said distributed application. 

Further, workflow management systems, referred to herein 
as WFMSs, are very preferred objects for being subjected 
to the improvements of the present invention. But 
basically, every system which is able to be described 

GE998-062 



with the basic structure and terminology of workflow 
management systems, further referred to as- WFMSs herein, 
can advantageously be improved by applying the method 
according to the invention. For the single reason of 
5 clear terminology, and thus improved clarity, the present 

invention will be disclosed herein in detail applied to 
WFMSs and with the terminology of SMS of Tivoli Systems 
Inc. 



10 A new area of technology with increasing importance is 

the domain of Workflow- Management- Systems (WFMS) . WFMS 
support the modeling and execution of business processes. 
Business processes control which piece of work of a 
network of pieces of work will be performed by whom and 

15 which resources are exploited for this work, i.e. a 

business process describes how an enterprise will achieve 
its business goals. The individual pieces of work might 
be distributed across a multitude of different computer 
systems connected by some type of network. 

20 

The process of designing, developing and manufacturing a 
new product and the process of changing or adapting an 
existing product presents many challenges to product 
managers and engineers to bring the product to market for 

25 the least cost and within schedule while maintaining or 

even increasing product quality. Many companies are 
realizing that the conventional product design process is 
not satisfactory to meet these needs. They require early 
involvement of manufacturing engineering, cost 

30 engineering, logistic planning, procurement, 

manufacturing, service and support with the design 
effort. Furthermore, they require planning and control 
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of product data through design, release, and 
manufacturing. 

The correct and efficient execution of business processes 
within a company, e.g. development or production 
processes, is of enormous importance for a company and 
has significant influence on a company's overall success 
in the market place. Therefore, those processes have to 
be regarded similar as technology processes and have to 
be tested, optimized and monitored. The management of 
such processes is usually performed and supported by a 
computer based process or workflow management system. 

In D. J. Spoon: "Project Management Environment", IBM 
Technical Disclosure Bulletin, Vol. 32, No. 9A, February 
1990, pages 250 to 254, a process management environment 
is described including an operating environment, data 
elements, and application functions and processes. 

In R. T. Marshak: "IBM FlowMark, Object-Oriented Workflow 
for Mission-Critical Applications", Workgroup Computing 
Report (USA), Vol. 17, No. 5, 1994, page 3 to 13, the 
object character of IBM FlowMark as a client /server 
product built on a true object model that is targeted for 
mission- critical production process application 
development and deployment is described. 

In H. A. Inniss and J. H. Sheridan: "Workflow Management 
Based on an Object-Oriented Paradigm", IBM Technical 
Disclosure Bulletin, Vol. 37, No. 3, March 1994, page 
185, other aspects of object-oriented modeling on 
customization and changes are described. 
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In F. Leymann and D. Roller: "Business Process Management 
with FlowMark", Digest of papers, Cat. No. 94CH3414-0, 
Spring COMPCON 94, 1994, pages 230 to 234, the state-of- 
the-art computer process management tool IBM FlowMark is 
described. The meta model of IBM FlowMark is presented 
as well as the implementation of IBM FlowMark. The 
possibilities of IBM FlowMark for modeling of business 
processes as well as their execution are discussed. The 
product IBM FlowMark is available for different computer 
platforms and documentation for IBM FlowMark is available 
in every IBM branch. 

In F. Leymann: "A meta model to support the modeling and 
execution of processes", Proceedings of the 11 th European 
Meeting on Cybernetics and System Research EMCR92, 
Vienna, Austria, April 21 to 24, 1992, World Scientific 
1992, pages 287 to 294, a meta model for controlling 
business processes is presented and discussed in detail. 

The "IBM FlowMark for OS/2", document number GH 19-8215- 
01, IBM Corporation, 1994, available in every IBM sales 
office, represents a typical modern, sophisticated, and 
powerful workflow management system. It supports the 
modeling of business processes as a network of 
activities; refer for instance to "Modeling Workflow", 
document number SH 19-8241, IBM Corporation, 1996. As 
further information on Workflow Management Systems 
available in IBM sales offices one could mention: IBM 
MQSeries Concepts and Architecture, document number GH 
12-6285; IBM MQSeries Getting Started with Buildtime, 
document number SH 12-6286; IBM MQSeries Getting Started 
with Runtime, document number SH 12-6287. This network 
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of activities, the process model, is constructed as a 
directed, acyclic, weighted, colored graph. The nodes of 
the graph represent the activities or workitems which are 
performed. The edges of the graph, the control 
connectors, describe the potential sequence of execution 
of the activities. Definition of the process graph is 
via the IBM FlowMark Definition Language (FDL) or the 
built-in graphical editor. The runtime component of the 
workflow manager interprets the process graph and 
distributes the execution of activities to the right 
person at the right place, e.g. by assigning tasks to a 
work list according to the respective person, wherein 
said work list is stored as digital data within said 
workflow or process management computer system. 

In F. Leymann and W. Altenhuber: "Managing business 
processes as an information resource' 1 , IBM Systems 
Journal, Vol. 32(2), 1994, the mathematical theory 
underlying the IBM FlowMark product is described. 

In D. Roller: "Verif ikation von Workflows in IBM 
FlowMark", in J. Becker und G. Vossen (Hrsg.): 
"Geschaef tsprozessmodellierung und Workflows", 
International Thompson Publishing, 1995, the requirement 
and possibility of the verification of workflows is 
described. Furthermore the feature of graphical 
animation for verification of the process logic is 
presented as it is implemented withing the IBM FlowMark 
product . 
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ysis, a process^ 
model has to be constructed as a network ofactjj&i^rareg'^ 
corresponding to the business proc£s-e-T"ln the IBM 
FlowMark product, the pro£ej9-S"**models are not transformed 
into an executable^^Ct run time, an instance of the 
process iscp^ated from the process model, called a 
proceg«^instance. This process instance is then 
==p*wrpreted dynamically oy tne ibm *uovma±^-proauct . 



10 



Generally speaking, workflow management, as for example 
implemented by IBM FlowMark, can be regarded as involving 
three dimensions. 



15 



The first dimension, the process logic dimension 
describes the actions to be performed, by whom they have 
to be performed, with which program they have to be 
performed, and in which sequence they have to be 
performed. 



20 



The second dimension describes the organizational 
structure, the people and the roles the people are 
playing. 



25 



The third dimension describes the information technology 
(IT) infrastructure, such as the workflow servers, and 
the workstations/programs used by the users. 



30 



The actual execution of a workflow is then a series of 
points in the three-dimensional workflow space. Each 
point represents the execution of an activity by one 
person at one computer using a particular program. 
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An application monitor is the part of an application that 
helps in monitoring the execution of the application. In 
workflow systems this component is called a process 
monitor. It tracks and controls the correct and timely 
5 execution of business processes. To achieve . that , the 

process monitor controls that sufficient resources are 
assigned to the individual activities and makes sure that 
the activities are carried out in a pre-defined time. If 
out-of-line situations occur, administration people are 
10 notified so that the appropriate corrective actions can 

be taken. 



A user typically interacts with the workflow management 
system via a graphical end user interface that represents 
15 the tasks to be performed by the user as icons. Work for 

a particular task is started by the user by double- 
clicking on the appropriate icon which in turn starts the 
program implementing the activity. 

20 It is important for the productivity of users that the 

invoked programs complete as designed and that they are 
not terminating prematurely as the result of a program 
internal or even external event, such as the breaking of 
a communication link or the malfunctioning of the 

25 workflow system itself. The reason for the event to 

happen could be either hard- or software failures. 
Unless the problem is fixed, users are prohibited for 
carrying out their duty efficiently. This indicates that 
the IT infrastructure is as important for the correct and 

30 efficient processing of workflow as is the organization 

which is monitored by the process monitor. 



GE998-062 



-7- 



3 



Said availability of systems including all hard- and 
software is controlled and monitored by said SMSs; that 
means the systems management system makes sure that the 
monitored systems are up and running and producing 
5 correct results. System in this context means the 

combination of hard- and software that performs a user- 
specified task, such as book keeping or loan processing. 
In general, a system is distributed, that means 
individual software components are running on different 
10 processors that are connected via communication lines. 

When an error is detected, typically a message is sent to 
the systems management system's enterprise console. This 
allows an operator to take appropriate actions; which 
15 actions need to be taken depends on some well in advance 

established procedures. 

The view that the SMS 1 s enterprises console exhibits is 
that of a set of hardware components and pieces of 
20 software only. It has been recognized that this view is 

too limited and that in order to get the whole picture 
one has to look at it from a business process 
perspective . 

25 TME-10, a state of the art SMS product sold by Tivoli 

Inc., a wholly owned subsidiary of IBM Corporation, is 
used as the prototype of a SMS, that means its 
implementation and terminology, for discussing SMS 
properties is used herein. 



30 



It has been proposed for TME-10,. whose basic structure 
and functions are described in more detail in the 
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introductory section, to provide that business process 
perspective view as a higher level of abstraction. 

This approach of presenting the managed hard -and software 
in a business process oriented view still has problems, 
however . 

It only reflects the relation between the IT- 
inf rastructure and the business processes and does not 
reflect other types of resources that are important for 
the processing of business processes, such as people 
working on the business processes. 

It is the object of the present invention to provide a 
business process oriented view of both the organization 
and the information technology aspects together by 
providing a linkage between the systems management 
systems and the distributed applications, in particular 
by the WFMS. This combined view can be implemented in 
the systems management system's enterprise console or in 
the application's application monitor, for workflow 
systems in the process monitor. 

SUMMARY OF THE INVENTION 

The present invention proposes a method and system for 
providing an improved consistency between the SMS and the 
WFMS by a linkage between the two. A tight, integrative 
linkage is provided which can be established, managed and 
maintained automatically by the application, and 
particularly by the WFMS, or, alternatively by the SMS. 
This allows the provision of a consistent business 
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process oriented view of the systems management system 
monitored resources, that means information technology 
resources, such as programs, and workflow management 
system monitored resources, that means organization 
resources, such as people. This is achieved by either of 
two ways : 

Either, by enhancing the application's monitor in order 
to include the functionality of the enterprise console 
and taking profit from the merged information of both 
systems, the SMS and the WFMS; or 

By enhancing the enterprise console in order to include 
the functionality of the WFMS 1 s process monitor and 
taking again profit from the merged information of both 
systems . 

This linkage is implemented in the first alternative by 
establishing a notification mechanism in the SMS that 
informs the WFMS about all processing relevant 
information technology related events and by implementing 
in the WFMS a mechanism that understands the sent 
notifications and takes appropriate actions. The set of 
actions can range from a simple alert to operations 
people via the process monitor or an automatic 
rearrangement of staff so that the affected workflows can 
continue to operate. 

For the second alternative, this linkage is provided by 
establishing a notification mechanism in the WFMS that 
informs the SMS about all processing relevant 
organization resource problems and by implementing in the 
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SMS a mechanism that understands the sent notifications 
and provides the appropriate information via the SMS 1 
enterprise console. 

5 Regardless of the chosen alternative, such a tight 

linkage allows to treat hard- and software errors as well 
as people resource problems as errors in the execution of 
business processes. 



10 The method of the present invention has the advantage, in 

relation to the method sketched out in the discussion of 
prior art technique, that a very consistent combined view 
of both SMS and application program, in particular the 
□ WFMS, is generated. 

H 2 15 

;;g Thus the process of handling errors is simplified and 

V3 more complete since hard- or software failures and 

in 

^ organizational resource problems are treated equally and 

yi are managed together. 

; L 20 

y 

M, In a preferred embodiment of the invention, the present 

method is applied to WFMSs. This extends the advantages 

f:a 

^ mentioned above for those systems. 

i a 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

Preferred embodiments of the present invention will now 
be described, by way of example only, with reference to 
the accompanying drawings in which: 

30 

Fig. 1 is an introductory diagram reflecting the first 
phase of the execution of an activity in a WFMS 



GE998-062 



showing the creation of work items according to 
prior art technique, 



Fig. 2 is an introductory diagram reflecting the 

second phase of the execution of an activity in 
a WFMS showing the execution of an activity 
implementation and it's access to 
resource/objects by the activity implementation 
according to prior art technique, 

Fig. 3 is a schematic sketch showing state-of-the-art 
SMS, 

Fig. 4 is a schematic block diagram showing the 

essential elements of SMS and WFMS, in the 
error event of Fig. 3, 

Fig. 5 is a schematic representation of a block 

diagram showing the control flow between SMS 
and WFMS improved according to the present 
invention, in case an error event occurs. 



DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS OF THE INVENTION 

The following is a short outline of the basic concepts of 
a workflow management system based on IBM ! s FlowMark WFMS 
and the state-of-the-art SMS TME-10 by Tivoli. This will 
lead directly to the inventive concept: 
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As workflow management systems are application programs, 
they are concerned by the present inventions. Thus, 
their basic functions are shortly summarized and set in 
context with the underlying invention: 

5 

From an enterprise point of view, the management of 
business processes is becoming increasingly important: 
business processes or process provide for the short 
control of which piece of work will be performed by whom 
10 and which resources are exploited for this work, i.e. a 

business process describes how an enterprise will achieve 
its business goals. A WFMS may support both, the 
modeling of business processes and their execution. 

15 Modeling of a business process as a syntactical unit in a 

way that is directly supported by a software system is 
extremely desirable. Moreover, the software system can 
also work as an interpreter basically getting as input 
such a model: The model, called a process model or 

20 workflow model, can then be instantiated and the 

individual sequence of work steps depending on the 
context of the instantiation of the model can be 
determined. Such a model of a business process can be 
perceived as a template for a class of similar processes 

25 performed within an enterprise; it is a schema describing 

all possible execution variants of a particular kind of 
business process. An instance of such a model and its 
interpretation represents an individual process, i.e. a 
concrete, context dependent execution of a variant 

30 prescribed by the model. A WFMS facilitates the 

management of business processes. It provides a means to 
describe models of business processes (built time) and it 
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drives business processes based on an associated model 
(run time). The meta model of IBM's WFMS FlowMark, i.e. 
the syntactical elements provided for describing business 
process models, and the meaning and interpretation of 
5 these syntactical elements, is described next. 

A process model is a complete representation of a 
process, comprising a process diagram and the settings 
that define the logic behind the components of the 
10 diagram. Using various services provided by FlowMark 

these buildtime definitions the process models are then 
converted into process templates for use by FlowMark at 
runtime. Important components of a FlowMark process 
3 model are: 

i is 



3 


I. 


Processes 


0 

Ft 


II. 


Activities 


j ;j 

3 


III. 


Blocks 


3 


IV. 


Control Flows 


a 20 


V. 


Connectors 




VI. 


Data Containers 


u 


VII. 


Data Structures 




VIII. 


Conditions 


5 


IX. 


Programs 


25 


X. 


Staff 



Not all of these elements will be described below. 

On this background a process, modeled by a process model 
30 within FlowMark, is a sequence of activities that must be 

completed to accomplish a task. The process is the top- 
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level element of a FlowMark workflow model. In a 
FlowMark process, it can be defined: 



I. How work is to progress from one activity to 

5 the next 

II Which persons are to perform activities and 

what programs they are to use 

10 II Whether any other processes, called 

subprocesses , are nested in the process 

Of course multiple instances of a FlowMark process can 
run in parallel. 

15 

Activities are the fundamental elements of the meta 
model. An activity represents a business action that is 
from a certain perspective a semantical entity of its 
own. With the model of the business process it might 

20 have a fine- structure that is then represented in turn 

via a model, or the details of it are not of interest at 
all from a business process modeling point of view. 
Refinement of activities via process models allows for 
both, modeling business processes bottom-up and top-down, 

25 Activities being a step within a process represents a 

piece of work that the assigned person can complete by 
starting a program or another process. In a process 
model, the following information is associated with each 
activity: 



30 



What conditions must be met before the activity 
can start 
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Whether the activity must be started manually 
by a user or can start automatically 



5 • What condition indicates that the activity is 

complete 

® Whether control can exit from the activity 

automatically or the activity must first be 
10 confirmed as complete by a user 



• How much time is allowed for completion of the 
activity 

15 • Who is responsible for completing the activity 

• Which program or process is used to complete 
the activity 

20 • What data is required as input to the activity 

and as output from it 



The activities to be performed have typically a fine 
structure : 

25 

An Activation Condition defines when the activity is 
ready for scheduling by the workflow manager; an Exit 
Condition defines when an activity should be treated as 
complete by the workflow manager. The core of the 
30 activity is the Task which is comprised of the proper 

activity and a query on an organization database. The 
Proper Activity associates the activity with a program 
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object. The program object defines for each operating 
system, and possibly for each user, the name and 
operational characteristics for an executable piece of 
software. The executable piece of software is started 
5 when the activity is performed by a user. The query on 

the organization database defines the persons responsible 
for performing the activity. When the activity is ready 
to be scheduled, the workflow management executes the 
specified query against the organization database. This 

10 query returns a set of persons, to which the activity is 

assigned to. The task is transformed into a set of work 
items, one for each person selected as the result of the 
query against the organization database. The work item 
contains the name of the person and the program to be 

15 executed. These work items are made part of the users' 

worklist. 

Each of the activities is performed by an activity 
implementation. The activity implementations are 
20 typically programs, but they may also be the invocation 

of a method object or a stored procedure in a relational 
data base. 

The results that are in general produced by the work 
25 represented by an activity is put into an output 

container, which is associated with each activity. Since 
an activity will in general require to access output 
containers of other activities, each activity is 
associated in addition with an input container too. At 
30 run time, the actual values for the formal parameters 

building the input container of an activity represent the 
actual context of an instance of the activity. Each data 
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container is defined by a data structure. A data 
structure is an ordered list of variables, called 
members, that have a name and a data type. Data 
connectors represent the transfer of data from output 
5 containers to input containers. When a data connector 

joins an output container with an input container, and 
the data structures of the two containers match exactly, 
the FlowMark workflow manager maps the data 
automatically. 

0 

A FlowMark process model consists of the following types 
of activities : 



Program activity: Has a program assigned to perform it. 

15 The program is invoked when the activity is started. In 

a fully automated workflow, the program performs the 
activity without human intervention. Otherwise, the user 
must start the activity by selecting it from a runtime 
work list. Output from the program can be used in the 

20 exit condition for the program activity and for the 

transition conditions to other activities. 

Process activity: Has a (sub- ) process assigned to perform 
it. The process is invoked when the activity is started. 
25 A process activity represents a way to reuse a set of 

activities that are common to different processes. 
Output from the process, can be used in the exit 
condition for the process activity and for the transition 
conditions to other activities. 



30 



The flow of control, i.e. the control flow through a 
running process determines the sequence in which 
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activities are executed. The FlowMark workflow manager 
navigates a path through the process that is determined 
by the evaluation to true of start conditions, exit 
conditions, and transition conditions. 

5 

Connectors link activities in a process model. Using 
connectors, one defines the sequence of activities and 
the transmission of data between activities. Since 
activities might not be executed arbitrarily they are 

10 bound together via control connectors. A control 

connector might be perceived as a directed edge between 
two activities; the activity at the connector's end point 
cannot start before the activity at the start point of 
the connector has finished (successfully) . Control 

15 connectors model thus the potential flow of control 

within a business process model. Default connectors 
specify where control should flow when the transition 
condition of no other control connector leaving an 
activity evaluates to true. Default connectors enable 

20 the workflow model to cope with exceptional events. Data 

connectors specify the flow of data in a workflow model. 
A data connector originates from an activity or a block, 
and has an activity or a block as its target. One can 
specify that output data is to go to one target or to 

25 multiple targets. A target can have more than one 

incoming data connector. 

Conditions are the means by which it is possible to 
specify the flow of control in a process. In FlowMark 
30 process models logical expressions can be defined that 

are evaluated by FlowMark at runtime to determine when an 
activity may start, end, and pass control to the next 
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activity. Start conditions are conditions that determine 
when an activity with incoming control connectors can 
start. The start condition may specify that all incoming 
control connectors must evaluate to true, or it may 
5 specify that at least one of them must evaluate to true. 

Whatever the start condition, all incoming connectors 
must be evaluated before the activity can start. If an 
activity has no incoming control connectors, it becomes 
ready when the process or block containing it starts. In 

10 addition, a Boolean expression called transition 

condition is associated with each control connector. 
Parameters from output containers of activities having 
already produced their results are followed as parameters 
referenced in transition conditions. When at run time an 

15 activity terminates successfully all control connectors 

leaving this activity are determined and the truth value 
of the associated transition conditions is computed based 
on the actual values of their parameters. Only the end 
points of control connectors the transition conditions of 

20 which evaluated to TRUE are considered as activities that 

might be executed based on the actual context of the 
business process. Transition conditions model thus the 
context dependent actual flow of control within a 
business process (i.e. an instance of a model) . Business 

25 processes encompass long running activities in general; 

such an activity needs to be allowed to become 
interrupted. Thus, termination of an activity does not 
necessarily indicate that the associated task has been 
finished successfully. In order to allow the measurement 

30 of successf ulness of the work performed by an activity a 

Boolean expression called exit condition is associated 
with each activity. Exactly the activities the exit 
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condition of which evaluated to true in the actual 
context are treated as successfully terminated. For 
determination of the actual control flow precisely the 
successfully terminated activities are considered. Thus 
5 the logical expression of an exit condition, if 

specified, must evaluate to true for control to pass from 
an activity or block. 

Beside describing the potential flow of control and data 
10 between activities a business process model also 

encompasses the description of the flow of the activities 
itself between resources actually performing the pieces of 
work represented by each activity. A resource may be 
3 specified as a particular program, person, a role, or an 

=; 15 organizational unit. At run time tasks are resolved into 

g requests to particular persons to perform particular 

3 activities resulting in work items for that person. 

ni 

4 Staff assignments are the means to distribute activities 
3 to the right people in the sequence prescribed by the 

- 20 control flow aspect of a business process model. Each 

* activity in a process is assigned to one or more staff 

yi members defined in the FlowMark database. Whether an 

^ activity is started manually by the user or automatically 

3 by the FlowMark workflow manager, and whether it requires 

25 user interaction to complete or completes automatically, 

a staff member must be assigned to it. FlowMark staff 
definition entails more than identifying people at your 
enterprise to the FlowMark database. For each person 
defined, you can specify a level, an organization, and 
30 multiple roles. These attributes can be used at run time 

to dynamically assign activities to people with suitable 
attributes. 
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Process definition includes modeling of activities, 
control connectors between the activities, input/output 
container, and data connectors. A process is represented 
as a directed acyclic graph with the activities as nodes 
and the control/data connectors as the edges of the 
graph. The graph is manipulated via a built-in, event - 
driven, CUA compliant graphic editor. The data 
containers are specified as named data structures. These 
data structures themselves are specified via the 
DataStructureDef inition facility. FlowMark distinguishes 
three main types of activities: program activities, 
process activities, and blocks. Program activities are 
implemented through programs. The programs are 
registered via Program Definition facility. Blocks 
contain the same constructs as processes, such as 
activities, control connectors etc. They are however not 
named and have their own exit condition. If the exit 
condition is not met, the block is started again. The 
block thus implements a Do Until construct. Process 
activities are implemented as processes. These 
subprocesses are defined separately as regular, named 
processes with all its usual properties. Process 
activities offer great flexibility for process 
definition. It not only allows to construct a process 
through permanent refinement of activities into program 
and process activities (top-down) , but also to build a 
process out of a set of existing processes (bottom-up) . 
In particular, process activities help to organize the 
modeling work if several process modelers are working 
together. It allows the team members to work 
independently on different activities. Program and 
process activities can be associated with a time limit. 
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The time limit specifies how long the activity may take. 
If the time is exceeded, a designated person is notified. 
If this person does not react within another time limit, 
the process administrator is notified. It not only helps 
to recognize critical situations but also to detect 
process deficiencies as all notifications are recorded in 
an audit trail. 

All data structures used as templates for the containers 
of activities and processes are defined via the Data 
Structure Definition Facility. Data Structures are names 
and are defined in terms of elementary data types, such 
as float, integer, or string and references to existing 
data structures. Managing data structures as separate 
entities has the advantage that all interfaces of 
activities and their implementations are managed 
consistently in one place (similar to header files in 
programming languages) . 

All programs which . implement program activities are 
defined via the Program Registration Facility. 
Registered for each program is the name of the program, 
its location, and the invocation string. The invocation 
string consists of the program name and the command 
string passed to the program. 

Before process instances can be created, the process 
model must be translated to ensure the correctness and 
completeness of the process model. The translated 
version of the model is used as a template when a process 
instance is created. This allows to make changes to the 
process model without affecting executing process 
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instances. A process instance is started either via the 
graphical interface of via the callable process 
application programming interface. When a process is 
started, the start activities are located, the proper 
5 people are determined, and the activities are posted onto 

the work list of the selected people as work items. If a 
user selects the work item, i.e. the activity, the 
activity is executed and removed from the work list of 
any other user to whom the activity has been posted. 

10 After an activity has executed, its exit condition is 

evaluated. If not met, the activity is rescheduled for 
execution, otherwise all outgoing control connectors and 
the associated transition conditions are evaluated. A 
control connector is selected, if the condition evaluates 

15 to TRUE. The target activities of the selected control 

connectors are then evaluated. If their start conditions 
are true, they are posted to the work list of selected 
people. A process is considered terminated, if all end 
activities have completed. To make sure that all end 

20 activities finish, a dead path elimination is performed. 

It removes all edges in the process graph which can never 
be reached due to failing transition conditions. All 
information about the current state of a process is 
stored in the database maintained by the server. This 

25 allows for forward recovery in the case of crashes. 

As already indicated above WFMS support the definition 
and execution of business processes. Those business 
processes are made up of a set of activities which are 
30 handled by different people at different places; business 

processes are therefore processed in most cases in a 
distributed environment comprising a network of a 



GE998-062 



-24- 



multitude of computer systems. The activities are 
generally implemented via programs that the user 
interacts with and that manage data that is associated 
with the process. A user typically interacts with the 
workflow management system via a graphical end user that 
represents the tasks to be performed by the user as 
icons. Work for a particular task is started by the user 
by double -clicking on the appropriate icon which in turn 
starts the program implementing the activity. 

The execution of an activity within a process is 
performed in two phases visualized in Fig. 1 and Fig. 2. 
Fig. 1 shows the first phase in which staff resolution is 
performed. When a process is defined, each activity is 
assigned an expression (staff assignment) that describes 
who should perform the activity. The staff assignment is 
expressed as a query against the organizational database 
that is part of the workflow management system. When the 
workflow management system navigates to an activity, it 
uses that query to find the people who should perform the 
activity (staff resolution). A work item 101, 102, 103 
is created for each of the selected persons. Depending 
on some settings, the work item is pushed immediately 
onto the work list 104, 105 of a selected person, or will 
be made part of the user's work list as the result of an 
explicit request. 

Fig. 2 shows the flow of control when the user starts a 
work item from the work list representing the second 
phase of execution of an activity. After double- clicking 
the work- item representing the execution request of the 
activity on the work list 2 01, the workflow management 
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system materializes the input container 202 and/or output 
container 203 and activates the program 205 that 
implements the activity 204. The program that is 
executed typically determines it's context by obtaining 
some or all of the fields in the input container, 
interacts with the user, retrieves or modifies some 
resources/objects 206, or date data for short, modifies 
the context by storing this information in the output 
container, and then terminates. This constitutes the 
completion of the activity, and navigation through the 
process graph continues. 

Next, the basic functions and structure of a SMS are 
described and are set into the context of the inventive 
concept . 

Two basic functions are typically provided by a SMS. 

Firstly, code distribution makes sure that the correct 
piece of code is installed at the correct level on the 
correct machine. 

Secondly, monitoring the operation helps to ensure that 
all hard- and software components are running as 
expected. If errors are reported to the SMS, the SMS 
performs error management as defined by the user, 
including making appropriate information available at the 
enterprise console. Then, the console operator may take 
appropriate steps via SMS provided functions. 

The flow of information within the SMS is as follows: The 
information is generated by some mechanism that is 
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typically outside the SMS . This set of raw information 
must be provided to an event adapter that transforms the 
raw information into formatted information which can then 
be processed by the event server, that performs the 
actual processing. 

The event adapter is written by the customer, i.e., the 
company which uses the application for performing its 
business processes. The event adapter processes the 
information coming from the event sources by first 
buffering them, filters the received information, selects 
the appropriate event server, formats the information and 
sends the formatted information to an event server for 
the actual processing. 

The event server receives the information from the event 
adapters . The events may be logged in an event log for 
later queries and reference. The events are classified 
before a customer provided rules engine determines the 
actions that need to be taken. The event server also 
invokes the actions that are determined by the rules 
engine. 

The actions that may be taken as a result of the rules 
engine processing are defined by the user. Typically a 
message is displayed on the enterprise console providing 
the console operator with the necessary information to 
take, if required, any resulting actions. Another common 
action is to invoke a program that performs all required 
actions automatically. 
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The view that the SMS exhibits is that of a set of 
hardware components and pieces of software. It is 
therefor rather difficult for the people designing the 
proper actions and for the master console operator to 
come up with the proper set of actions without doing more 
harm than good. The SMSs are addressing this issue by 
providing different levels of abstractions. 

In Fig. 3 the different levels of abstraction are shown. 
The lowest level represents the network; management of it 
is done via SMNP, the standard protocol for managing 
networks. On the next level are the individual software 
components, such as the different pieces of the operating 
system, the middleware components, such as database 
systems or WFMSs, or individual pieces of application 
software. The third level, that has been proposed by 
Tivoli, addresses the fact that application systems are 
made up of different components; a book keeping system 
for example may use a database system to store data. 

^ Hav in g d - i-f-f-e n en L levels allows to easier understand trnp^ 
impact of any error situation by propaga±^ig-- ; fefeertr^^m 
the lower levels to the hi^h^^dvels. This allows for 
example the en^tgtp^irSeconsole operator to see the 
impact^cU-'djSplication system instead of just a piece of 

Even the notion of application systems, the level of 
abstraction is still below what is needed to understand 
the dependencies between the different pieces of software 
that are involved. This level of abstraction can only be 
achieved by looking at the system from a business process 
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point of view. Instead of looking at the individual 
components, the system is viewed as a collection of 
business processes, where each of the business processes 
is connected to a set of application systems and 
5 application components. 

One solution to this is to enhance the SMS enterprise 
console with a business process view. The SMS would need 
to access the WFMS 1 s repository and use the appropriate 
10 process structures to present the managed system in the 

structure of business processes. If an error occurs, the 
appropriate activity would be shown as in error. The 
console operator could then dig deeper into the 

3 structures managed by the SMS and find out exactly what 

-J 15 needs to be done. 

3 WFMSs are pro- active systems; that means they take 

pi 

*! actions if out-of-line situations occur. To support this 

3 behavior, they allow to associate with construct of a 

20 business process appropriate performance characteristics 

£ and the action to be taken in case the specified 

: it 

:J performance characteristics are not met. One might, for 

3 

example, specify that an activity must be processed 
3 within a day and if not completed in one day, that the 

25 manager of the employee assigned to the task should be 

informed. 

The component of the WFMS that helps to manage the 
business processes, that means monitors and takes 
30 appropriate actions, is the process monitor. It provides 

an application programming interface that allows to build 
a graphical end user interface to assist process 



GE998-062 



-29- 



administrators to identify problems and to take 
appropriate actions. 

If defined properly, either explicitly or via defaults, 
all errors, either hard- or software, are eventually 
detected by the process monitor. If, for example, a 
connection brakes for a program, it would show up as a 
problem in the throughput of the activity that is 
associated with the particular program. The process 
monitor would now help the process administrator to find 
out whether this is a people related problem or not. If 
it is not people related, the graphical end user 
interface could inquire the WFMS using the WFMS supplied 
application programming interface to identify the related 
activity implementation. With this information, the SMS 
could be contacted for further analysis. 

This approach is also not completely satisfactory for 
basically two reasons: First, it may just take too long 
until an error manifests itself as a problem detected by 
the process monitor, and second, the appropriate setup 
lacks usability because two APIs are required. 

It is required that any error occurring during performing 
an activity can be detected quickly and handled from a 
business point of view. Otherwise, the user is waiting 
unproductively before any interaction can be performed. 

Thus, the present invention seeks to improve the overall 
performance of an application, particularly of WFMSs, by 
providing an improved consistency between systems 
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management systems and their respective distributed 
applications . 

The present invention provides a method to achieve a 
tight integration between the two systems. In a 
preferred embodiment the WFMS included the SMS pieces 
into its process monitor. 

With general reference to the Figures and with special 
reference now to Fig. 4 and Fig. 5 the essential elements 
taking part in the inventional method for providing an 
improved consistency between an application program where 
a WFMS depicted inside a frame 8 and the SMS depicted 
inside a frame 9 and the respective control flow in case 
of an error event occurring are described below. 

In Fig. 4 a program 10 which shall perform an activity- 
block 210 in Fig. 5 as a part of the underlying 
applications business process is monitored by the SMS. 
Any problem associated with the application program 10 is 
detected -block 220- by a program 12 that serves as event 
source 12. 

Fig. 4 indicates that the event source 12 signals this 
event forward to the event adapter 14. The program that 
generates the event, which is the event source, typically 
uses program specific methods to detect that the program 
10 does not function properly. If the program 10 for 
example reads from a queue, the event source program 12 
could periodically inquire the queue to see if the number 
of messages in the queue is increasing or whether the 
program is still having contact with the queue. It 
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should be noted that detecting problems and creating the 
raw data as explained above is typically a customer 
responsibility and is no essential feature of the method 
of the present invention. 

The appropriate event information is then sent to the 
event adapter 14 that manages -block 230- the raw data as 
described above. In the example depicted in Fig. 4, 
where a program is monitored, such work consists 
principally of routing the event forward -block 240- to 
the event server 16. 

The event server 16, treats then -block 250- the event 
according to customer specified rules. Depending on the 
type of error- see bifurcation in Fig. 5, an appropriate 
notification is sent -blocks 260, 265- to the WFMS 22. 
This is achieved by the event monitor calling a program 
18 that sends an appropriate notification 19 to the WFMS. 
This program may need to access a control file 20 that 
contains, for example, information which one of a 
plurality of WFMSs should be informed. 

When the event is not required to be notified to the WFMS 
-possibly due to an automatic error correction performed 
by the SMS- and state-of-the-art event handling -block 
261- can also be allowed to be performed. 

The WFMS 22 accepts -block 265- the notification 19 and 
uses -block 270- the sent information to locate the 
affected process models and then determines the affected 
activities. As the process monitor knows the 
organizational aspects of the WFMS a proposal is 
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possible. This information is then made available to any 
interested party via the process monitor's programming 
interface. This can then be graphically represented in 
the process monitor's console 24. 

5 

By that a process administrator is enabled to determine 
the reason of the problem and then to take appropriate 
actions -block 280- . 

10 By establishing and maintaining the notification 

mechanism and a corresponding mechanism how to understand 
and process such notification 19 an inventional 
'communication bridge' depicted as 25 is setup between 
i SMS and WFMS as could be seen from above. By that, a 

J 15 tight integration of both systems is achieved. 

0! Then, the workflow processing can continue -block 290- . 

Hi 

3 The following changes are advantageously undertaken to 

20 achieve the communication bridge 25 between SMS and WFMS 

I, in order to establish the tight integration just outlined 

il above. These changes are needed operating under the base 

3 

; assumption that no changes to the actual SMS code are 

j 

3 necessary; alternatively, the notification program 18 

25 could be incorporated into the SMS itself. 

If the restriction that the SMS can not be modified is 
lifted, that means the SMS is modified, some or all of 
the following changes might have to be modified or may 
30 even not be necessary anymore. 
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First, it is required to provide the necessary additions 
to the SMS f s event definitions. 



Secondly, it is required that the WFMS accepts external 
5 notifications, such as the one sent from the notification 

program triggered by the SMS ' s event monitor. 

Optionally, extensions to the application programming 
interface of the WFMS can be supplied, and further 
10 optionally, an automatic analysis of errors can be 

supported. 

Said changes are described next below: 

ji 

i 15 Concerning first the additions, as was shown above, the 

g WFMS is informed about events by the notification program 

9 18 that is triggered by the SMS ' s event monitor. This 

n 

a- term is used and deemed to include the event source 12, 

3 the event adapter 14 and the mechanism needed to locate 

20 and to message the IT -related error event. Said 

* notification program 18 is typically supplied by the 

U WFMS, however, this is not a necessity. Any. program that 

*J is capable of informing the WFMS is sufficient. This 

3 program must then be defined as an action in the event 

25 server for each of the programs that are carried out. 

All information that is needed by the program, such as 
which WFMS should be informed, can be generated by the 
WFMS since the WFMS has all necessary information in its 
30 repository. The WFMS could also help in generating the 

appropriate entries that need to into the definitions for 
the event server 16. 
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Next, the notification mechanism as an important part of 
the communication bridge 25 according to a preferred 
embodiment of the present invention works as follows: 

The notification program 18 informs the WFMS by sending 
appropriate information to the WFMS, which then allows 
the WFMS to locate the impacted activities and processes 
and determine the correct course of actions. Typical 
pieces of information that are sent are the name of the 
failing program and the failure reason. Additional 
information may include for example expected down time. 
When the WFMS receives such a notification, it hands it 
over to it's process monitor component for further 
processing . 

The information provided enable the process monitor to 
perform any kind of actions ranging from simply 
displaying an error message, issuing an alert to even 
take corrective actions, including reassigning of work to 
different people, to allow the workflow to continue. 

In addition, the WFMS must be enhanced to understand the 
notification sent to it by a program, in particular the 
notification program that is triggered by the SMS. This 
new function is exposed either via an application 
programming interface or by a set of messages or by both. 

If the process monitor component 24 of the WFMS and thus 
the WFMS is now the only interface for managing the 
system, it is beneficial -but not anyhow required- that 
the WFMS provides a single application programming 
interface for managing all system aspects. That means, 
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the process monitor's API should be enhanced to expose 
the underlying SMS 1 application programming interface. 

The process monitor's graphical end user interface could 
then use this enhanced application programming interface 
to allow a process administrator to obtain seamlessly all 
available information. 

With the information available to the process monitor 24 , 
it is possible for the process monitor to direct the 
process administrator directly to the cause of error, 
whether it is some organization- related problems or just 
the failure of some piece of hard- or software. Thus, 
the operator can undertake appropriate steps in order to 
support the business process disturbed by the event. 

In a modification of the above described embodiment of 
the present invention the enterprise console of the SMS 
is enhanced instead of the process monitor. 

This requires that a communication bridge or linkage is 
established between the WFMS and the SMS. 

The event server of the SMS in enhanced to understand 
events generated by the WFMS. This is implemented by 
adding specific events with corresponding event actions. 
These event actions are then reflected at the enterprise 
console of the SMS. 

The enterprise console is enhanced for processing said 
event actions by providing it with a set of predetermined 
rules in order to manage said business process. These 
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rules can include all relevant information which could 
ever be provided by the WFMS itself concerning how the 
event hindered business process could be further 
continued in order to achieve the business goal. 

While the invention has been particularly shown and 
described with respect to preferred embodiments thereof, 
it will be understood by those skilled in the art that 
the foregoing and other changes in form and details may 
be made therein without departing form the spirit and 
scope of the invention. 
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